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(54) System and method for generating trusted, architecture specific, compiled versions of 
architecture neutral programs 

(57) A distributed computer system has a program 
conpiling computer and a program executing computer. 
The program compiling computer is operated by a com- 
piling party and includes a conpiler that, when the dig- 
ital signature of the originating party of an architecture 
neutral program has been verified. (A) compiles the 
architecture neutral program code of the architecture 
neutral program into architecture specific program code 
In the architecture specific language identified t>y the 
compile to information in the architecture neutral pro- 
gram, and (B) appends to the architecture specific pro- 
gram code a digital signature of the compiling party to 
generate an architecture specific program. The program 
executing computer is operated by an executing party 
and includes an architecture specific program executer 
that executes the architecture specific program code of 
the architecture specif ic program when the digital signa- 
ture of the originating party of the architecture neutral 
program has been verified, the digital signature of the 
compiling party of the architecture specific program has 
been verified, and the compiling party has t»een deter- 
mined to be a menri)er of a defined set of trusted com- 
piling parties. 
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Description 

The present invention relates generally to distributed computer systems, and particularly to a program compilation 
system and method in which architecture neutral executable programs are compiled by a taisted third party in such a 
way that recipients of the compiled program can verify the identity of the con-esponding architecture neutral program 
and can verify that it was conpiled by the trusted third party. 

BACKGROUND OF THE INVENTION 

Tlie term "architecture" is defined for the purposes of this document to mean the operating characteristics of a fam- 
ily of computer models. Examples of distinct architectures are: Macintosh computers, IBM PC compatible computers 
using the DOS or Windows operating systems. SUN Microsystems conputers running the Solaris operating system, 
and computer systems using the Unix operating system. 

The term "architecture neutral" Is defined for the purposes of this document to refer to ability of certain programs, 
such as programs written in the Java (a trademark of Sun Microsystems, Inc.) language, to be executed on a variety of 
computer platforms using a number of different computer architectures. 

The term "architecture specific" is defined for the purposes of tills document to refer to the requirement that certain 
programs be executed only on conputer platforms using a single computer architecture. For instance, object code pro- 
grams written in tiie 80486 assembler language can only be executed on conputeis using the IBM PC conpatiWe com- 
puter architecture (as well as in otfier computers tiiat contain IBM PC conpatiWe conputer emulators). 

Important features of architecture neutral programs (ANPrograms) include the architecture independence of pro- 
grams written in tiie architecture neutral language (ANLanguage). For example. Java bytecode programs can be exe- 
cuted on any computer platform having a Java bytecode interpreter. An additional important feature of Java bytecode 
programs is tiiat their integrity can be directly verified prior to execution by a Java bytecode verifier. A Java bytecode 
verifier determines whether the program conforms to predefined integrity criteria. Such criteria include operand stack 
and data type usage restrictions that ensure that Java bytecode programs cannot overflow or underflow the executing 
computer's operand stack and tfiat all program instructions utilize only data of known data types. As a result, a Java 
bytecode program cannot aeate object pointers and generally cannot access system resources other than those which 
the user has explicitiy granted it permission to usa 

Unfortunately, distributing executable programs in an ANLanguage causes the ANProgram to run less effidentiy 
than it wouW if it could take advantage of architecture specific features -Fbr exanple. Java bytecode programs executed 
by a Java bytecode interpreter typically run 2.5 to 5 times as slow as the equivalent architecture specific programs 
(ASPrograms) corrpiled in corresponding architecture specrfk; languages (ASLanguages). While a fector of five speed 
reduction is actually considered to be unusually good for an ANProgram executer (i.e.. interpreter), it is a sufficient loss 
of efficiency that some users will require or insist upon the ability to use equivalent programs compiled in an ASLan- 
guage. 

Compilers that can compile an ANProgram into an equivalent ASProgram can be written. However, tfiey may be 
prohibitively expensive for the end user. In addition, the integrity of the equivalent compiled ASProgram cannot be ver- 
ified directiy from tiie compiled ASProgram code by an ANProgram integrity verifier. Thus, in tiie case of Java bytecode 
programs, the use of ANPrograms compiled into equivalent ASPrograms potentially results in the toss of one of the 
most valuable features of an ANLanguage, 

However, there are some legitimate (or legaO tasks that can be performed by integrity non-verifiable ASPrograms 
but which cannot be perfomied by integrity verifiable ANPrograms. These include tasks that would othenMse violate the 
operand slack and data type usage restrictions imposed on the Integrity verifiable ANPrograms. In addition, such 
ASPrograms can be executed much faster than ANPrograms. As a result, tfiere are number of reasons why it is desir- 
able to have a computer system that is designed to primarily execute integrity verifiable ANPrograms but also has the 
capatMlity of executing integrity non-verifiable ASPrograms. 

Although compilation of ANPrograms by a third party is posstole. such compilations require that tfie third party be 
autiienticated. That is. it must be possible to verify from tiie infornnation in the compiled ASProgram ttiat it was compiled 
by a specific trusted tfiird party. Even better, it should also be possible to autiienticate ttiat the corrpiled ASProgram was 
generated by a specific trusted compiler. And. since the integrity of the conpiled ASProgram witti respect to predefined 
integrity aiteria cannot be directiy verified, the conpiled ASProgram should include information that in a verifiable man- 
ner identifi^ the corresponding ANProgram from which it was compiled and the ASLanguage in which it was conpiled. 

Embodiments of tiie present invention provide an ANProgram compiler and conpilation method tfiat enables ttie 
user of an ASProgram conpiled from a corresponding ANProgram to autfienticate the klentify of who conpiled tiie 
ANProgram, tiie identity of ttie corresponding ANProgram. and tiie ASLanguage in which the ASProgram was com- 
piled. 

Embodiments of the present invention also provide an ANProgram executer and executton metfiod tfiat enables 
integrity verifiable ANPrograms being executed to call integrity non-verifiable ASPrograms that are trusted or that have 
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verifiable sources and compilation tnfomiation so that essentially all legitimate tasks can be performed, while preventing 
from being called ASPrograms whose sources, compilation information, and integrity cannot be verified. 

SUMMARY OF THE INVENTION 

5 

In summary, the present invention is a computer network that comprises a program compiling computer and a pro- 
gram executing computer. 

The program compiling computer is operated by a compiling party and includes storage that stores an architecture 
neutral program generated by an originating party. The architecture neutral program contains architecture neutral pro- 

10 gram code and a digital signature of the originating party. The program compiling computer also includes a signature 
verifier that verifies the digital signature of the originating party to verify that signature of the originating party matches 
(i.e., was generate using) the architecture neutral program to which it is attached. 

The program compiling conrputer further includes a compiler that, when the digital signature of the originating party 
has been verified compiles the architecture neutral program code into architecture specific program code in the archi- 

15 tecture specific language identified by the compile to information. The compiler utilizes a signature generator to append 
to the architecture specific program code a digrtal signature of the compiler program, where the compiler signature 
signs a set of information that includes the compiled architecture specific program code plus the signature on the archi- 
tecture neutral program. In the preferred embodiment the compiler utilizes the signature generator to also appends to 
the architecture specific program code a digital signature of the compiling party, where compiling party signature signs 

20 a set of information that includes the compiled architecture specific program code, the signature on the architecture 
neutral program and the compiler signature. 

The program executing computer is operated by an executing party and includes storage that stores the architec- 
ture neutral and specific programs. It further includes a signature verifier that (A) verifies the digital signature of the orig- 
inating party in the architecture neutral program, and (B) verifies the digital signature of the compiler in the architecture 

25 specific program and/or verifies the digrtal signature of the compiling party in the architecture specific program. The 
term Verifies a signature" means that a procedure is performed to determine that the signature matches (i.e.. was in 
fact generated from) the set of information allegedly signed by the signature. 

The program executing corrputer also includes an architecture specific program executer that, when the digital sig- 
natures in the architecture specific program have been verified, executes the architecture specific program code of the 

30 architecture specific program. 

In the preferred embodiment, the architecture neutral prograrp is embodied in an object that contains a digital sig- 
nature that includes a message digest uniquely associated with the architecture neutral program. The architecture spe- 
cific program generated by the compiler includes: 

35 • the compiled, architecture specific code; 

the digital signature of the corresponding architecture neutral program as signed by the party that provided the 
architecture neutral program; 

a digrtal signature by the compiler itself, including a message digest of the compiled program and information iden- 
tifyirig the compiler used to corrpile the program, and signed using the compiler's private encryption key; and 
40 • a digital signature by the trusted party performing the compilation, including a message digest of the compiled pro- 
gram and information identifying the trusted party, and signed using the compiling part/s private encryption key. 

A generally available, trusted repository of public encryption keys, sometimes called a naming service, holds the 
pMic keys for the compiler and the trusted compiling party. Using these public enayption keys all recipients of the com- 
45 piled program can decrypt the digital signatures in the compiled program to verify that the compiled program was com- 
piled by the indicated trusted party and by the indicated compiler, and also to verify the identity of the corresponding 
architecture neutral program. Optionally, the recipient of the compiled program can use a program verifier to verify the 
proper operation of the corresponding architecture neutral program prior to executing the compiled architecture specific 
program. 

50 

BRIEF DESCRIPTION OF THE DRAWINGS 

Examples of the inventk>n will be described in corijurx^tion with the drawings, in which: 

65 Fig. 1 IS a t)lock diagram of a distritxited computer system incorporating a preferred emtxxJiment of the present 
invention. 

Fig, 2 depicts the structure of an architecture neutral program in accordance with a preferred embodiment of the 
present invention. 
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Fig. 3 depicts the structure of a compiled, architecture specific, program generated in accordance with a preferred 
embodiment of the present invention. 

Fig. 4 depicts an object and associated object class in accordance with a preferred embodiment of the present 
5 Invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Referring to Fig. 1, there is shown a computer network 100 having many client computers 102, a server computer 

10 104, and a trusted key repository 106. The client computers 102 are connected to each other and the server computer 
104 and the trusted key repository 106 via a network communications connection 108. The network communications 
connection may be a local or wide area network, the Internet, a combination of such networks, or some other type of 
network communications connection. 

While most of the client computers 102 are desktop computers, such as Sun workstations. IBM compatible com- 

75 puters, and Macintosh computers, virtually any type of computer could be a client computer. Each of these client com- 
puters includes a CPU 110. a user interface 112, a memory 114. and a network communications interface 116. The 
network communications interface enables the client computers to communicate with each other, the server computer 
104, and the trusted key repository 108 via the network communications connection 106. 

The memory 114 of each client computer 102 stores an operating system 118. a network communications man- 

20 ager 120. an ANProgram (architecture neutral program) executer 122. an ASProgram (architecture specific program) 
executer 124, and ANProgram integrity verifier 126. an ANProgram compiling preparer 128, a signature generator 130, 
a signature verifier 132. a compiling information (Complnfb) verifier 134, an object class loader 136. a user address 
space 138, a trusted object class repository 140. an untrusted object class repository 142. and lists 144 of known, 
trusted compiling parties and trusted compilers. The operating system is run on the CPU 1 10 and controls and coordi- 

25 nates running the programs 120-136 on the CPU in response to commands issued by a user with the user interface 
112. 

The ANProgram executer 122 of each client computer 102 executes ANPrograms in the object classes stored in 
the trusted and untrusted object dass repositories 140 and 142. Moreover, the ANPrograms are written in an ANLan- 
guage for which the user may establish predefined integrity criteria, such as stack and data usage restrictions, so that 
30 the ANPrograms will not perform illegal tasks. Thus, the integrity of the ANPrograms can be directly verified by the 
ANProgram integrity verifier 126 prior to execution by determining if the program satisfies tiie predefined integrity crite- 
ria. These ANPrograms are therefore considered integrity verifiable ANPrograms. 

In the preferred embodiment, the integrity verifiable ANPrograms are written in the Java bytecode language. More- 
over, the ANProgram executer 122 and the ANProgram verifier 124 are respectively a Java bytecode program inter- 
as preter and a Java bytecode program verifier that respectively execute and verify the Java bytecode programs. The Java 
bytecode verifier and interpreter are products of Sun Microsystems, Inc. 

However, each client computer 1 02 has an associated specific architecture for which programs may be written in a 
con-esponding ASLanguage and executed by the ASProgram executer 122. The ASLanguage does not require that 
ASPrograms written in the ASLanguage satisfy the predefined integrity criteria of the ANLanguage. As a result the 
40 ASPrograms can perform tasks that cannot be performed by the ANPrograms because they are not burdened by the 
restrictions imposed by the predefined integrity criteria of the ANLanguage. Unfortunately, however, this also means 
that their integrity cannot be directiy verified by the ANProgram integrity verifier 126 and are therefore conskJered integ- 
rity non-verifiable. 

Nevertiieless, as indicated eariier, an ANProgram runs less efficiently than the same program compiled in an 
45 ASl-anguage. Thus, the user of a dient computer 102 may wish to have an ANProgram conpiled by the server conpu- 
ter 104 for the ASLanguage associated with the users dient computer so the compiled ASProgram can be executed 
there by the ASProgram executer 124. Or, the user may wish to have the ANProgram compiled for the ASLanguages 
associated with other dient computers if the compiled ASPrograms are going to be distributed and executed by the 
ASProgram executers 124 of other client computers. 

so 

Preparing an Architecture Neutral Program for Compiling 

Refening to Rgs. 1 and 2. when an originating party (OrigParty) wishes to have an ANProgram 200 compiled by 
the server computer 104. the OrigParty issues a command witii the user Interface 1 12 to invoke the ANProgram com- 
55 piling preparer 128 and instrud it to prepare the ANProgram for compiling. The ANProgram may be in an object dass 
contained in one of the taisted or untrusted object dass repositories 1 40 or 1 42. Table 1 contains a pseudocode repre- 
sentation of the procedure used by the ANProgram compiling preparer 128 to prepare the ANProgram for compiling by 
the server computer 104. The pseudocode used in Tables 1-3 uses universal computer language conv^ntbns. While 
the pseudocode employed here has been invented solely for the purposes of this descriptk>n, it is designed to be easily 
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understandable by any computer programmer skilled in tlie art. 

Referring to Figs. 1 and 2 and Table 1 , the ANProgram compiling preparer 128 first calls the ANProgram integrity 
verifier 126 and instructs it to verify the integrity of the ANProgram code 202 of the ANProgram 200, This is done to 
make sure that the ANProgram code satisfies the predefined integrity criteria of the ANLanguage prior to being sent to 
5 the server computer 104 for compiling. If the ANProgram code does not satisfy the predefined integrity criteria, the 
ANProgram integrity verifier sends back a failed result to the ANProgram compiling preparer. In response, the ANPro- 
gram compiling preparer aborts the compiling preparation procedure and generates an appropriate message indicating 
this. 

However, if the ANProgram code 202 does satisfy the predefined integrity aiteria, then the ANProgram integrity ^ 

10 verifier 126 sends back a passed result to the ANProgram compiling preparer 128, The ANProgram compiling preparer 
then calls the signature generator 130 and instructs it to generate the OrigParty's digital signature (DigitalSignatureop) 
210 that can be verified to ensure that the ANProgram 200 was generated by the trusted OrigParty The signature gen- 
erator generates the DigitalSignatureop by first generating a message digest (MDqp) 212 of the ANProgram code 202, 
It does this by computing a hash function. HashFunctionop on the data bits of the ANProgram code. The hash function 

15 used may be either a predetermined hash function or one selected by the OrigParty For purposes of this document, 
the HashFunctionop con-esponds to the OrigParty since it was used for the DigitalSignatureop of the OrigParty. 

The signature generator 130 then encrypts the generated massage digest (MDqp) 212 and the ID of the Hash- 
Functionop (HashFunctionop ID) 214 with the private encryption key of the OrigParty (OrigParty's PrivateKey), The sig- 
nature generator then adds the OrigParty's ID 216 in dear text at the end of the encrypted iterm 212 and 214 to form 

20 the DigitalSignatureop The OrigParty's PrivateKey and ID are provided by the OrigParty with the user interface 1 1 2. 

After the DigitalSignatureop 210 is generated, the ANProgram compiling preparer 128 appends it to the ANPro- 
gram code 202. Then, the ANProgram compiling preparer generates a message that the ANProgram 200 has been pre- 
pared for compiling by the server computer 104. 

The OrigParty then issues with the user interface 112 a command to the network communications manager 120 to 

25 transmit the ANProgram 200 to the server computer 1 04, along with arguments specifying the architecture specific lan- 
guage into which the program is to be compiled (ASLanguage ID) and the compiler to be used (Compiler ID). The net- 
work communications manager retrieves the ANProgram from the trusted or untrusted object dass repository 140 or 
142 In which it is located and provkies it to the network communications interface 1 16, The network communications 
manager then instructs the network communications interface to transmit the ANProgram to the server computer along 

30 with the specific arguments. 

Compiling an Architecture Neutral Program 

The transmitted ANProgram 200 is then received at the server computer 1 04, The server computer includes a CPU 
35 1 50, a user interface 1 52, a memory 1 54. and a network communications interlace 1 56. The network communications 
interface enables the server computer to communicate with the client computers 1 02 and the trusted key repository 106 
via the network communications connection 1 08. 

The memory 1 54 of the server computer 1 04 stores an operating system 1 58. a network communications manager 
160. an ANProgram conpiler 162, a signature verifier 164, an ANProgram integrity verifier 166. a signature generator 
40 168. an ANProgram repository 170, and an ASProgram repository 172. The operating system is run on the CPU 150 
and controls and coordinates running the programs 160-168 on the CPU in response to commands issued by a com- 
piling party (CompParty) with the user interface 152. 

The networi< communications interface 156 receives the ANProgram 200 and insti-ucts the network communica- 
tions manager 160 that this has occurred. In response, network communications manager places the received ANPro- 
45 gram in the ANProgram repository 170. It the server 104 is set up as an automatic compiler service, this is done 
automatically by the network communications manager 160, Othenwise. the ANProgram is moved into repository 170 
by the network communications manager when the CompParty issues a command with the user interface. 

Then, either automatically, or upon the issuance of a command by the CompParty with the user interface 252. the 
ANProgram compiler 162 is invoked to compile the ANProgram 200. Table 2 contains a pseudocode representation of 
60 the compilation procedure used by the ANProgram compiler to compile the ANProgram. 

Referring to Rgs. 1-2 and Table 2, the ANProgram compiler 162 first calls the signature verifier 164 to verify the 
DigitalSignatureop 210 in the received ANProgram 200 so as to establish tiiat the DigitalSignatureop 210 is actually the 
originating party's signature for the ANProgram {e.g.. as opposed to being a forged signature or the OrigParty signature 
on some other version of tiie ANProgram). In particular, the signature verifier uses the QearText OrigParty's ID 216 in 
55 the received ANProgram to obtain the OrigParty's Put>licKey from the trusted key repository 106. Then the signature 
verifier decrypts the encrypted MDqp 212 and HashFunctionop ID 214 in the DigitalSignatureop using the public 
encryption key of the OrigParty (OrigParty's PublicKiey). 

Next the signature verifier 164 generates a test message digest (TestMDop). which should match the decrypted 
MDqp 212, by computing the corresponding HashFunctionop on the ANProgram code 202 of the received ANProgram 
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200. The HashFunctionop ID 214 in the decrypted DigrtalSignature^p is used to identify the proper HashFunctionop to 
be used. The decrypted MDqp and the generated TestMDop are then compared to verify the DigitalSignatureop 210. 

If the MDqp 212 and the TestMDop do not match, then the signature verifier 162 sends back a failed result to the 
ANProgram compiler 162. In response, the ANProgram compiler aborts the compiling procedure and generates an 
5 appropriate message. 

On the other hand, if the MDqp and the TestMDop do match, then the signature verifier 162 sends back a passed 
result to the ANProgram compiler 162 and the ANProgram compiler calls the ANProgram integrity verifier 166. It 
Instructs the ANProgram integrity verifier to verify the integrity of the ANProgram code 202 of the received ANProgram 
200. This is done In the same manner and for the same purpose as was desaibed earlier in the section discussing pre- 

10 paring the ANProgram for compiling. Thus, If the ANProgram code does not satisfy the predefined integrity criteria, the 
ANProgram integrity verifier sends back a failed result to the ANProgram compiler. In response, the ANProgram com- 
piler attorts the compiling procedure and generates an appropriate message indicating this. 

However, if the ANProgram code 202 of the received ANProgram 200 does satisfy the predefined integrity criteria, 
then the ANProgram integrity verifier 166 sends tack a passed result to the ANProgram compiler 162. The ANProgram 

IS compiler then compiles the ANProgram code into the ASLanguage identified by the ASLanguage ID specified by the 
OrlgParty. Referring now to Figs. 1 -3 and Table 2, the conpiler places the ANProgram code 202, the DigitalSignatureop 
210 and the compiled ASProgram code 302 In an ASProgram 300 that Is stored in the ASProgram repository 172. 

The ANProgram compiler 162 then calls the signature generator 168 and Instructs rt to generate the ANProgram 
compiler's digital signature (DigitalSignatureo) 320 which can be verified to ensure that the ASProgram 300 was com- 

20 piled with the trusted ANProgram conpiler. This is done In a manner similar to that described earlier for generating the 
DigitalSignatureop However, in this case, the set of information signed is the ASProgram code and the DigitalSignatur- 
eop Another predetermined hash function with a corresponding HashFunctionc ID 324 may be used to generate the 
message digest MDq 322 of the set of information to be signed by the DigitalSignaturec. the private encryption key of 
the ANProgram compiler (Compiler's PrivateKey) is used to enaypt the MD^ and the HashFunctionc ID, and the iden- 

25 tifier of the ANProgram compiler (Compiler's ID) is added in dear text at the end of the encrypted MDc and HashFunc- 
tionc- "I^e Conpiler's PrivateKey and ID are provided by the ANProgram compiler. 

The ANProgram compiler 162 calls the signature generator 168 a second time to generate the CompParty's digital 
signature (DigitalSignaturecp) 312. which can be verified by end users to ensure that the ASProgram 300 was gener- 
ated by the trusted CompParty. This is done in a similar manner to that described earlier for generating the DigtlalSig- 

30 natureop (in the section discussing preparing an ANProgram for compiling). However, here the message digest (MDcp) 
314 generated for the DigitalSignatureop is generated by computing a predetermined or selected hash function (Hash- 
Functioncp) on the data bits of the ASProgram code, the DigitalSignatuerop and the DigitalSignaturec. Similar to the 
HashFunctionop for purposes of this disclosure, the HashFunctionop corresponds to the CompParty since it was used 
for the DigitalSignaturecp of the CompParty. 

35 The signature generator 168 then encrypts the MDcp 314 and the ID of the HashFunctionop (HashFunctionop ID) 
31 6 with the pri>^te enayption key of the CompParty (CompParty's PrivateKey). The signature generator then adds the 
identifier of the CompParty (ConpPart/s ID) 318 in dear text at the end of the encrypted items 314 and 316 to form 
the DigitalSignaturecp 312. The CompParty's PrivateKey and ID are provided by the CompParty with the user interface 
152. 

40 After the DigitalSignaturec 320 and the DigitalSignaturecp 312 are generated, the ANProgram compiler 162 
appends them to the ASProgram. code 302, so that the resulting compiled ASProgram ffle or object has the following 
components in it: 

ANProgram Code, 
45 DigitalSignatureop 
ASProgram Code, 
DigitalSignaturec. and 
DigitalSignatureop 

so Then, the ANProgram compiler generates a message that the ANProgram 200 has l>e€n compiled to form the ASPro- 
gram 300 and Is ready to be sent to the OrigParty. 

The CompParty then uses the network communications manager 160 to transmit the ASProgram 300 to the Grig- 
Party's client computer 102. The network communications manager does so by retrieving the ASProgram from the 
ASProgram repository 1 72 in which it Is kx^ated and provides it to the network communications interface 1 56. The net- 

55 work communrcations meinager than instruds the network communications interface to transrrwt the ASProgram to the 
OrlgParty's client computer. 
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Object and Object Class Creation and Distribution 

The transmitted ASProgram 300 is then received by the communications interface 116 of the OrigParty's dient 
conputer and instructs the network communications manager 120 that this has occurred. In response, the OrigParty 

5 issues a command with the user interface 252 to instruct the network communications manager to retrieve the received 
ASProgram from the network communications interface, causing the network communications manager to place the 
received ASProgram in the untrusted object class repository 142 of the OrigParty's client computer. Once this is done, 
the OrigParty may treat the received ASProgram as a new object class with just one method (i.e. the compiled program 
code), or it may aeate an object class that includes the ASProgram 300 as well as other ANPrograms and ASPro- 

10 grams. 

Fig. 4 shows a typical object class 400 in accordance with the present invention. The object class may include one 
or more ASPrograms 402 and/or one or more ANPrograms 404. as well as a virtual function table 410. For each ASPro- 
gram, the virtual function table contains a con-esponding identifier (native_ASProgram ID) 412 that indicates tfiat it is 
an ASProgram fi.e., a native program) that is not in the ANLanguage and a corresponding pointer (Ptr) 41 4 to the native 

15 program. Similarly, for each ANProgram. the virtual function tatrfe contains a corresponding identifier (ANProgram ID) 
416 and a con-esponding pointer 418 to the ANProgram. Every object 420 of this object class includes an object header 
422 that points to the object class 400. 

Thus, the OrigParty may create an object 420 and an object class 400 wrtii the ASProgram 300 that was received 
from the server computer 104 as one of the ASPrograms 402 in the object class. 

20 When the OrigParty wishes to distribute to various ExecuteParties an object and object class that includes the 
ASProgram 300 and ANProgram, then the OrigParty issues a command with the user interface 1 12 to instruct the net- 
work communications manager to transmit these items to the client computer 102 of the ExecuteParties. The network 
communications manager does this by reti^ieving them from the untrusted object dass repository 142 in which tiiey are 
located and provides them to the network communications interface 116 with appropriate transmission instructions. 

25 Alternately, tiie network comnuinications manager of tiie OrigParty may respond to a request initiated by an Exe- 
cuteParty for a copy of a specified object class 400. 

Execution of Architecture Neutral Programs and Architecture Specific Programs In an Object Class 

30 The network communications interface 156 of the client computer 102 receives the transmitted object and object 
class and instructs the network communications manager 160 tii^t this has occurred. In response, the ExecuteParty 
issues a command with tiie user interface 1 1 2 to instruct the network communications manager to retrieve the received 
object and object dass from tiie network comn^nications interface. The network communications manager tiien stores 
the received object and object class in the unti-usted object dass repository 1 42. 

35 The umrusted object dass repository 142 of each dient computer 102 contains the objects and tiieir associated 
object dasses that are not trusted. These object dasses are not trusted because any ANPrograms they include have 
not yet had their integrity verified and any ASPrograms they include have not had their source verified nor have been 
verified as being compiled from the proper ANProgram. 

The trusted object dass repository 140 of each dient computer contains the objects and their object dasses that 

40 are taisted. "These object classes are trusted because any ANPrograms they include may have already had their integ- 
rity verified by the ANProgram integrity verifier 136 and any ASPrograms tiiey contain have been ascertained to be 
trustworthy. In fact, some or all the object dasses in tiie trusted object dass repository 140 need not have digital signa- 
tures, because these object dasses are trusted and therefore there is no reason to perform integrity checks on the 
methods in these object classes. 

45 ft is desirable to have an object dass that primarily includes ANPrograms but may also indude ASPrograms so that 
essentially ail legitimate tasks can be performed with the object dass, as suggested eariier. Therefore, the ANProgram 
executer 122 is capable of executing integrity verifiable ANPrograms and calling the ASProgram executer to execute 
integrity non-verifiable ASPrograms that are either (1) in trusted object classes in the trusted object dass repository 
140, or (2) that are in untrusted object dasses in the untrusted object dass repository 142 and have verifiable Digital- 

60 Signatureop DigitalSignaturecp and DigitalSignaturec information so that essentially all legitimate tasks can be per- 
formed. In this way, ASPrograms of untrusted object dasses that doni have DlgitalSignatureop DigitalSignaturecp and 
DigitalSignaturec information or wtiose digital signatures cannot be verified are prevented from being executed. Table 
3 contains a pseudocode representation of the execution procedure used by the ANProgram executer. 

Refen-ing to Rgs. 1-4 and Table 3. at the dient computer 102 of an ExecuteParty (e.g., the OrigParty or another 

55 party), the ANProgram executer 124 may be executing an ANProgram that seeks to call a mettiod in a specified object 
dass. The metfxxJ call is initially handled by the object dass toader 136. which detemiines whetfier or not the object 
dass has already been loaded. If the object dass has already been loaded into the ExecutePart/s user address space 
138, then the ANProgram executer 122 executes the called method H the called method is an ANProgram and the 
ASProgram executer 124 executes the called mettiod if tiie called metiiod is an ASProgram. 
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However, if the object class has not yet been loaded into the ExecuteParty's address space 138, then the object 
class loader 136 loads the object class into the ExecuterParty's address space and determines whether or not execu- 
tion of the called method is to be allowed. For instance, if the object class was loaded from the trusted object dass 
repository 140, then execution of the called method is permitted and the Execute procedure is called. The Execute pro- 
cedure (see Table 3) calls the ANProgram executer if the called method is an ANProgram, and othenwise calls the 
ASProgram executer 124 to execute the called method. 

However, if the object class was loaded from the untrusted object class repository 142, the class loader 136 exam- 
ines the object header of the object to determine if its object class includes any ASPrograms. It does so by determining 
if there any native_ASProgram IDs in the virtual function table of the object. 

If there are no ASPrograms in the object class, then the class loader 1 36 calls the ANProgram integrity verifier 1 36 
to verify the integrity of the ANPrograms in the object dass. This is done in the same manner and for the same purpose 
as was described earlier for verifying the integrity of the ANProgram 200 (in the section discussing compiling an ANPro- 
gram). Thus, if the integrity of any of the ANPrograms is not verified, then the ANProgram integrity verifier passes back 
to the class loader a failed result and the dass loader aborts the class loading procedure and generates an appropriate 
message indicating this. But, if the ANProgram integrity verifier sends back a passed result indicating that all of the 
ANPrograms of the object dass are verified, the dass loader enables execution of the called method. 

If there are any ASPrograms in the object dass. then the dass loader 136 calls the signature verifier 132 to verify 
the compiler signature DigitalSignaturec and the CtompParty signature DigitalSignaturecp If any of the ASPrograms 
does not include a DigitalSignaturecp and a DigitalSignaturec. the integrity of the ASProgram's source cannot be veri- 
fied aiKl therefore the signature verifier sends back to the ANProgram executer a failed result. In response, the dass 
loader aborts the object class loading procedure and generates an appropriate message that this has occun-ed. 

Further, if all of the ASPrograms in the object class do indude a DigitalSignaturecp and a DigitalSignaturec. the 
identities of the CJompParty and the Compiler as indicated in these two digital signatures, are compared with the lists 
144 (see Fig. 1 ) of known, trusted Compiler Parties and trusted Compilers. If any of the ASPrograms in the object dass 
were compiled by a ConpParty or a Compiler not included in the set of known, trusted Compiler Parties and trusted 
Compilers, the dass loading procedure is aborted, and execution of the called method is thereby trfocked. Similarly, if 
the ASLanguage identified in any of the ASPrograms does not match the ASLanguage used by the ASProgram Exe- 
cuter 124, the class loading procedure is aborted. 

However, if all of the ASPrograms in the object dass do indude a DigitalSignaturecp and a DigitalSignaturec, and 
the identified CompParty and Compiler for all the ASPrograms are trusted Conpiler Parties and Compilers, and the 
ASLanguage used by all the ASPrograms is one used by the ASProgram Executer, then the signature verifier verifies 
these signatures in a similar manner as was described earlier for verifying the DigitalSignaturecp (in the section dis- 
cussing compiling the ANProgram 200). However, in this case, the Compiler's and CompParty's public keys are 
retrieved from the trusted key repository 106 and respectively used to decrypt the MDc and HashFunctionc ID in the 
DigitalSignaturec and the MDcp and the HashFunctioncp ID in the DigitalSignaturecp Furthermore, the test message 
digests (TestMDc and TestMDcp) con-esponding to the decrypted MDcp and MDc are generated by computing hash 
codes on the data bits of the ASProgram code plus the DigitalSignaturecp for the TestMDc arxl on the same data bits 
plus the DigitalSignaturec for the TestMDcp according respectively to the HashFunctionc and HashFunctioncp identi- 
fied by the decrypted HashFunctionc ID and HashFundioncp ID. 

If the DigitalSignaturec and/or the DigitalSignaturecp is rxrt verified (i.e., MDc ^ TestMDc and/or MDcp ^ TestM- 
Dcp) for every ASProgram, then the signature verifier 136 sends back to the dass loader 136 a failed result. In 
response, the dass loader aborts the dass toading procedure and generates an appropriate message that this has 
occurred. 

However, if the DigitalSignaturec and the DigitalSignaturecp are both verified (i.e., MDc = TestMDc and MDcp = 
TestMDcp) fo*' every ASProgram, then the ANProgram executer 124 again calls signature verifier 132 to verify the Orig- 
Part/s signatures (DigitalSignaturecp) for the ANPrograms from which the ASPrograms were compiled. To verify the 
OrigParty digital signatures, the DigitalSignaturecp of each is verified in the same manner as was discussed eariier in 
the section concerning compilation of the ANProgram 200. 

If the DigitalSignaturecp of each of the ANPrograms from which the ASPrograms were conpiled is verified, then 
the dass loader calls the ANProgram integrity verifier to verify the integrity of every ANProgram in the object dass and 
the ANPrograms from which the ASPrograms were compiled. This *fs done in the same manner as was descrtoed ear- 
lier, ff the integrity of any of these ANPrograms is not verified, then the ANProgram integrity verifier sends back Id the 
dass toader a failed result, which aborts the class loading procedure and generates an appropriate message. 

However, if the integrity of each of the ANPrograms is verified, then the ANProgram integrity verifier 126 sends 
back a passed result to the dass toader 136. In response, the dass loader invokes the ANProgram executer or ASPro- 
gram executer to execute the called method, as appropriate. 

In view of the foregoing, the ExecuterParty is assured that only those untrusted object dasses in the untrusted 
repository 142 that have integrity verifiable ANPrograms and ASPrograms whose digital signatures can be verified will 
be loaded and have their programs executed. 
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Alternative Embodiments 

Some of the features of the invention described above are optional. Thus, those skilled in the art will recognize that 
alternative ent>odiments exist that dont include these features. 

For example, the ANProgram compiler has been described as generating both a DigitalSignaturecp and a Digital- 
Signaturec respectively for the CompParty and the ANProgram compiler. However, the ANProgram compiler could be 
constructed simply to generate only one of these digital signatures for enabling verification of the either the compiler 
used to compile the ASProgram or the compiling party. 

Similarly the program executer has been described as requiring verification of both a DigitalSignaturecp and a 
DigitalSignaturec. However, the program executer could be constructed to require verification of only one of these dig- 
ital signatures and optionally verify the other digital signature if the ASProgram being verified includes it. Furthermore, 
the program executer could be constructed to skip the step of verifying the integrity of the ANProgram corresponding to 
each ASProgram. based on the assumption that the compiling party is trusted and that it is a duty of the compiling party 
to verify the integrity of each ANProgram that Is compiles Into an ASProgram prior to performing the compilation. 

When the ExecuterParty Is the OrigParty. the ExecuterParty knows that it actually sent the ANProgram 200 to the 
CompParty's server computer 104 to be compiled into the ASProgram 300. in this case, the class loader 136 could be 
constructed to not call the signature verifier to verify the DigtlalSignatureop in the ANPrdgram. Rather, the Executer- 
Party can sirrply compare the DigtlalSignatureop in the local copy of the ANProgram with the DigtlalSignatureop in the 
conpiled ASProgram. Additionally, the class loader could be constructed to not call the ANProgram integrity verifier 126 
to verify the integrity of the ANProgram corresponding to a called ASProgram since the integrity of the ANProgram 
would have been checked during the preparation for compiling procedure prior to being sent to the compiling server 
conputer. Alternatively, the ANProgram compiling preparer 128 could be constructed to not call the ANProgram integ- 
rity verifier during the preparation for compiling procedure since its integrity would be checked both by the compiler and 
when the class loader calls the ANProgram integrity verifier prior to execution of the corresponding ASProgram. 

TABLE 1 

Pseudocode Representation of Method of Preparing Architecture 
Neutral Program for Connpiling 

Procedure: Prepare for Compiling (ANProgram code. OrigParty's PrivateKey. and 
OrigParty's ID) 

Verify integrity of ANProgram with ANProgram integrity venfier 
If failed result 

{ abort and generate failed result message } 
Generate MDqp = HashFunctionop (ANProgram code) 

Generate DigitalSignaturecp = Encrypt (MDop + HashFunctionop ID, OrigParty's 

PrivateKey) + ClearText (OrigParty's ID) 
Append DigitalSignatureop to ANProgram code 
Generate message that ANProgram is prepared for compiling 
Return 
} 
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TABLE 2 

Pseudocode Representation of Method of Compiling ANPrograo) and 
Generating ASProgram 

Procedure; Compile (ANProgram, CompParty's ID. ASLanguagelD. CompParty's 
PrivateKey, Compiler's ID, and Compiler's PrivateKey) 
{ 

Retrieve OrigParty's PublicKey from trusted key repository using ClearText 

OrigParty's ID in DigltalSignatureop 
Decrypt (MDqp + HashFunctionop ID in DigitalSignatureop, OrigParty's 

PublicKey) 

Generate TestMDop = HashFunctionop (ANProgram code) using 
HashFunctioHop identified by decrypted HashFunctionop ID 

Compare decrypted MDqp and TestMDop 

If decrypted MDqp * TestMDop 
{ 

/* DigitalSignatureop of OrigParty not verified */ 

Generate failed result message 

} 

Else 

{ 

r DigitalSignatureop of OrigParty has been verified */ 
Verify integrity of ANProgram with ANProgram integrity verifier 
If failed result 
{ 

abort and generate failed result message 
} 

Else 

{ 

r ANProgram has been verified */ 

Compile ANProgram code into ASLanguage identified by 

ASLanguage ID to generate ASProgram code 
Generate MDc = HashFunctioncs (ASProgram code + 

DigitalSignatureop) 
Generate DigltalSignaturCc = Encrypt (MDc + HashFunctionc ID. 

ANProgrom Compiler's PrivateKey) + ClearText 

ANProgram Compiler's ID 
Generate MDcp = HashFunctioncp (ASProgram code + 

DigitalSignatureop + DigitalSignaturec) 
Generate DigitalSignatureop = Encrypt (MDcp + HashFunctionop 

ID, CompParty's PrivateKey) + ClearText CompParty's ID 
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Generate and Return File or Object containing: 

ANProgram Code, 

DigitalSlgnatureop, 

ASProgram Code, 

DigltalSignaturec, and 

DigitalSignaturecp 
r ASProgram has been compiled and generated 
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TABLE 3 

Pseudocode Representation of Method of Executing 
Architecture Specific Program 

Procedure: Execute (ObjectClass, Program) 
{ 

If the Program is a verifiable program 

{ Execute Program using the Bytecode Interpreter} 
Else 

{ Execute Program using the compiled program executer } 

} 

Procedure: ClassLoad (ObjectClass, Program) 
{ 

If Object Class has already been loaded into ExecuterPart/s address space 
{ 

Call Execute (ObjectClass, Program) 

Retum 

} 

/* The Object Class has not been loaded */ 
Load Object Class into ExecuterParty's address space 
If Object Class was loaded from Trusted Object Class Repository 
{ 

Call Execute (ObjectClass, Program) 

Retum 

} 

/* Object Class was loaded from Untrusted Object Class Repository */ 
If Object Class does not contain any ASPrograms designated as 

native_ASPrograms in Object Header of Object 

{ 

Verify Integrity of ail ANPrograms of Object Class with ANProgram integrity 

verifier 
If failed result 

{ 

Abort with appropriate failed result message 
} 

Else 

r Integrity of all ANPrograms of Object Class have been verified */ 
{ Call Execute (ObjectClass, Program) } 
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Return 
} 

r Object Class does contain ASPrograms designated as native_ASPrograms in 

Object Header of Object V 
If any ASProgram does not contain a DigitalSignaturecp and a DigitalSlgnaturec 

{ 

r Compiling Party and Compiler of every ASProgram cannot be verified */ 

Generate appropriate message 

Retum 

} 

For each ASProgram in Object Class: 

{ Determine identity of CompParty and Compiler and determine 
ASLanguage used by ASProgram } 
If identity of CompParty for any ASProgram is not a known, trusted. Compiling 

Party, or the identity of Compiler is not a known, trusted Compiler, or the 

identified ASLanguage is not one used by the ASProgram Executer 

{ 

Generate appropriate message 

Retum 

} 

For each ASProgram in Object Class: 

Retrieve CompPart/s PublicKey from trusted key repository using ClearText 

CompParty*s ID in DigitalSignaturCcp 
Decrypt (MDcp + HashFunctioncp ID in DigitalSignaturecp, CompParty's 

PublicKey) 

Generate TestMDcp = HashFunctioncp (ASProgram code + DigitalSignatureop 
+ DigitalSignaturCc in ASProgram) using HashFunctioncp identified by 
decrypted HashFunctioncp ID 

Compare decrypted MDcp and TestMDcp 

} 

If decrypted MDcp ^ TestMDcp for any ASProgram 
{ 

/* DigitalSignaturecp for every ASProgram has not been verified */ 

Generate appropriate failed result message 

Retum 

} 

r DigitalSignaturecp for every ASProgram has been verified*/ 
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For each ASProgram in Object Class: 
{ 

Retrieve ANProgram Compiler's PublicKey from trusted key repository using 
ClearText ANProgram Compiler's ID in DigitalSignaturec 

Decrypt (MDc + HashFunctionc ID in DigitalSignaturcc. ANProgram 
Compiler's PublicKey) 

Generate TestMDc = HashFunctionc (ASPragram code + DigitalSignature^p) 
using HashFunctionc identified by decrypted HashFunctionc ID 

Compare decrypted MDc ^"^1 TestMDc 

} 

If decrypted MDc ^ TestMDc for any ASProgram 
{ 

r DigttalSignaturec for every ASProgram in Object Class has not been 
verified */ 

Generate appropriate failed result message 

Return 

} 

r DigitalSignaturCc for every ASProgram in Object Class has been verified */ 
For each ANProgram from which an ASProgram in Object Class was compiled: 

{ 

Retrieve OrigParty's PublicKey from trusted key repository using ClearText 

OrigParty's ID in DigitalSlgnaturOop 
Decrypt (MDqp + HashFunctionop ID in DigitalSignatureop. OrigParty's 

PublicKey) 

Generate TestMDop = HashFunctionop (ANProgram code) using 
HashFunctionop Identified by decrypted HashFunctionop ID 
Compare decrypted MDqp and TestMDop 
} 

If decrypted MDqp ^ TestMDop for any ANProgram 
{ 

f* DigitalSignatureop for every ANProgram from which an ASProgram in 

Object Class was compiled not verified */ 
Generate failed result message 
Return 
} 

r The DigitalSignatureop in every ASProgram in Object Class is verified */ 
Verify integrity of ANPrograms in Object class and ANPrograms from which 

ASPrograms in Object Class were compiled with ANProgram integrity verifier 
If failed result 

{ 
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Generate failed result message 

Return 

} 

/* Integrity of all ANPrograms In Object class and all ANPrograms from which 

ASPrograms in Object Class were compiled have been verified */ _ 
Call Execute (ObjectClass, Program) 
} 
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Claims 



1 , A computer network that conprises: 

20 

a program compiling conputer operated by a compiling party, the program compiling computer receiving an 
architecture neutral program generated by an originating party, the architecture neutral program containing 
architecture neutral program code and a digital signature of the originating party that when verified verifies that 
the architecture neutral program was signed by the originating party, the program compiling computer includ- 
es ing; 



a signature verifier that verifies the originating party's digital signature; 

a compiler that generates an architecture specific program when the originating party's digital signature 
has been verified, the compiler generating the architecture specific program by (A) compiling the architec- 
30 ture neutral program code into architecture specific program code in an architecture specific language, and 

(B) appending a digital signature of the compiling party that when verified verifies that the architecture spe- 
cific program was generated by the compiling party; and 
a signature generator that generates the compiling party's digital signature; and 

35 a program executing computer operated by an executing party, the program executing computer receiving the 

architecture specific program and receiving or originating the architecture neutral program, the program exe- 
cuting computer including: 

a signature verifier that verifies the compiling party's digital signature; and 
40 an execuler that executes program code that is in the architecture specif ic language, the executer execut- 

ing the architecture specific program code when the compiling part/s signature has been verified and the 
compiling party is a member of a defined set of trusted compiling parties. 



2, A computer network as in daim 1 wherein: 

the signature generator generates a digital signature of the compiler that when verified verifies that the archi- 
tecture specific program was generated with the compiler; 

the corrpiler generating the architecture specific program further by appending to the architecture specific 
program code the compiler's digital signature; 

the executing computer's signature verifier verifies the compiler's digital signature; 

the executer executing the architecture specific program code only after the compiler's digital signature has 
been verified and the compiler is determined to be a member of a defined set of trusted compilers. 



3. A computer network as in claim 1 wherein: 

for the originating and compiling parties, said network includes corresponding private and pitolic encryption 
55 keys and corresponding hash functions; 

the originating party's digital signature includes a message digest of the architecture neutral program gen- 
erated by perforating the originating part/s con-esponding hash function on the architecture neutral program, the 
message digest of the architectLre neutral program toeing encrypted with the originating party's conresponding pri- 
vate key; 
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the program cxjmpiling computers' signature verifier includes instructions for verifying the originating party's 
digital signature by (A) decrypting the message digest of the architecture neutral program with the originating 
party's public encryption key. (B) generating a corresponding test message digest of the architecture neutral pro- 
gram by perfaming the originating party's hash function on the architecture neutral program code, and (C) compar- 
5 ing the decrypted message digest and the test message digest of the architecture neutral program; 

the signature generator includes instructions for generating the compiling party's digital signature by (A) 
generating a message digest of the architecture neutral program generated by performing the compiling party's 
corresponding hash function on the architecture specific program code, arxJ (B) encrypting the message digest of 
the architecture specific program with the compiling party's con-esponding private key: and 

the program executing computer's signature verifier includes instructions for verifying the compiling party's 
digital signature by (A) decrypting the message digest of the architecture specific program with the compiling 
party's public enayption key (B) generating a corresponding test message digest of the architecture specific pro- 
gram by performing the compiling party's hash function on the architecture specific program code, and (C) compar- 
ing the decrypted message digest and the test message digest of the architecture specific program. 

16 

4. A computer network as in claim 1 wherein; 

the program executing computer further includes an architecture neutral program integrity verifier that veri- 
fies the integrity of the architecture neutral program code by verifying that the architecture neutral program code 
satisfies predefined program integrity criteria; 
20 the executer executes the architecture specific program code only after the integrity of the architecture neu- 

tral program code has been verified, 

5. A computer network as in claim 1 further comprising: 

26 a program originating computer that provides the architecture neutral program, the program originating com- 

puter including: 

a signature generator that generates an originating party's digital signature that is appended to the archi- 
tecture neutral program code; 

30 . 

the program compiling computer communicating with the program originating computer to receive the architec- 
ture neutral program from the program aiginating computer and to provide the architecture specific program 
to the program originating computer; 

the program executing computer communicating with the program originating computer to receive the architec- 
ts ture neutral and specific programs from the program originating computer; 

the program executing computer's signature verifier also verifying the originating party's digital signature; 
the executer executing the architecture specific program only after the originating part/s digital signature has 
been verified. 

40 6. A metiiod of operating a computer network comprising the steps of: 

at a program compiling computer operated by a compiling party: 

receiving an architecture neutral program generated by an originating party, the architecture neutral pro- 
45 gram containing architecture neutral program code and a digital signature of tie originating party that 

when verified verifies that tiie architecture neutral program was signed by the originating party; 
verifying the originating party's digital signature; and 

compiling tiie architecture neutral program with a conpiler so as to generate an architecture specific pro- 
gram when the originating part/s digital signature has been verified, and appending a digital signature of 
50 the compiling party that when verified verifies that the architecture specific program was generated by tiie 

compiling party; and 

at a program executing computer operated by an executing party: 

65 receiving the architecture spectfk; program and receiving or originating tiie architecture neutral program; 

verifying the compiling party's digital signature; and 

executing the architecture specif k; program when the compiling part/s signature has been verified and the 
compiling party is deterntined to be a member of a defined set of trusted compiling parties. 
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7. The method of claim 6, including: 

at the program compiling computer: 

generating a digital signature of the compiler that when verified verifies that the architecture specific pro- 
gram was generated with the compiler; and 

appending to the architecture specific program code the compiler's digital signature; and 
at the program executing computer : 

verifying the compiler's digital signature: and 

executing the architecture specific program only after the compiler's digital signature has been verified and 
the compiler is determined to be a member of a defined set of trusted compilers. 

15 8. The method of claim 6, wherein 

for the originating and compiling parties, said network includes con-esponding private and public encryption 
keys and con*esponding hash functions; 

the originating party's digital signature Includes a message digest of the architecture neutral program gen- 
erated by performing the originating part/s corresponding hash function on the architecture neutral program, the 
20 message digest of the architecture neutral program being encrypted with the originating party's corresponding pri- ' 
vate key; 

said method Including the steps of: 



at the program compiling computer: 



26 



verifying the originating part/s digital signature by (A) deaypting the message digest of the architecture 
neutral program with the originating party's public encryption key, (B) generating a corresponding test 
message digest of the architecture neutral program by performing the originating party's hash function on 
the architecture neutral program code, and (C) comparing the decrypted message digest and the test mes- 
30 sage digest of the architecture neutral program; arxi 

generating the compiling party's digital signature by (A) generating a message digest of the architecture 
neutral program generated by performing the compiling party's corresponding hash function on the archi- 
tecture specific program code, and (B) enaypting the message digest of the architecture specific program 
with the compiling party's corresponding private key; and 



35 



at the program executing computer: 



verifying the compiling party's digital signature by (A) decrypting the message digest of the architecture 
specif k; program with the compiling part/s public encryption key, (B) generating a corresponding test mes- 
40 sage digest of the architecture specific program by performing the compiling part/s hash function on the 

architecture specific program code, and (C) comparing the decrypted message digest and the test mes- 
sage digest of the architecture specific program. 

9. The method of daim 6, Including: 

45 

at tiie program executing computer: 

verifying the integrity of the architecture neutiBi program code by verifying that the architecture neutral pro- 
gram code satisfies predefined program integrity criteria; and 
50 executing the architecture specific program code only after the integrity of the architecture neutral program 

code has been verified. 

10. The method of dalm 6. further induding: 

55 at a program originating computer tiiat provides tiie architecture neutral program: 

generating the originating party's digital signatijre and appending it to the architecture neutral program 
code; 
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at the program compiling conputer: 

communicating with the program originating computer to receive the architecture neutral program from the 
program originating computer and to provide the architecture specific program to the program originating 
computer; 

at the program executing computer: 

communicating with the program originating conriputer to receive the architecture neutral and specific pro- 
grams from the program originating computer; 
verifying the originating party's digital signature; and 

executing the architecture specific program only after the originating party's digital signature has been ver- 
ified. 

1 1 . The method of claim 6. including: 

at the program executing computer: 

providing the architecture neutral program; 

generating an originating party's digital signature that signs said architecture neutral program and append- 
ing it to the architecture neutral program code; arKJ 

at the program compiling computer: 

communicating with the program executing computer to receive the architecture neutral program from the 
program executing computer and to provide the architecture specific program to the program executing 
computer 

12. A system for distributing code stored on computer-readable media and executable by computers, the code includ- 
ing a plurality of modules each configured to carry out at least one function to be executed by one of the computers, 
the system comprising: 

a first module configured for use in conjunction with a program conpiling computer, operated by a compiling 
party, that receives an architecture neutral program generated by an originating party, the architecture neutral 
program containing architecture neutral program code and a digital signature of the originating party that when 
verified verifies that the architecture neutral program was signed by the originating party, the first module 
including; 

a signature verifier that verifies the originating party's digital signature; 

a compiler that generates an architecture specific program when the originating part/s digital signature 
has been verified, the compiler generating the architecture specific program by (A) conpiling the architec- 
ture neutral program* code into architecture specific program code in an architecture specific language, and 
(B) appending a digital signature of the compiling party that when verified verifies that the architecture spe- 
cific program was generated by the compiling party; and 
a signature generator that generates the compiling party's digital signature; and 

a second module for use in conjunction with a program executing computer, operated by an executing party, 
tfiat receives the architecture specific program and receives or originates the architecture neutral program, the 
second module including: 

a signature verifier that verifies the compiling part/s digital signature; and 

an executer that executes program code that is in the architecture specific language, the executer execut- 
ing the architecture specific program code when the compiling party's signature has been verified and it 
has been determined that compiling party is a member of a defined set of trusted compiling parties. 

1 3. A system as in claim 12 wherein: 

the signature generator generates a digital signature of the compiler that when verified verifies that the archi- 
tecture specific program was generated with the compiler; 

the first module appends to the architecture specific program code the compiler's digital signature; 
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the second module's signature verifier verifies the compiler's digital signature; 

the second module's executer executes the architecture specific program code only after the compiler's dig- 
ital signature has been verified and it has been determined that compiler is a member of a defined set of trusted 
compilers. 

5 

14. A system as In claim 12 wherein: 

for the originating and compiling parties;, said system includes corresponding private and public encryption 
keys and corresponding hash functions; 

the originating party's digital signature includes a message digest of the architecture neutral program gen- 
re erated by performing the originating party's caresponding hash function on the architecture neutraP program, the 
message digest of the architecture neutral program being encrypted with the originating party's corresponding pri- 
vate key; 

the first module's signature verifier includes instructions for verifying the originating party's digital signature 
by (A) decrypting the message digest of the architecture neutral program with the originating party's public encryp- 
15 tion key. (B) generating a corresponding test message digest of the architecture neutral program by performing the 
originating party's hash function on the architecture neutral program code, and (C) comparing the deaypted mes- 
sage digest and the test message digest of the architecture neutral program; 

the first module's signature generator includes instructions for generating the compiling party's digital signa- 
ture by (A) generating a message digest of the architecture neutral program generated by performing the compiling 
20 party's corresponding hash function on the architecture specific program code, and (B) enaypting the message 
digest of the architecture specific program with the compiling party's corresponding private key; and 

the second module's signature verifier includes instructions for verifying the compiling party's digital signa- 
ture by (A) decrypting the message digest of the architecture specific program with the compiling party's public 
encryption key. (B) generating a con^esponding test message digest of the architecture specific program by per- 
25 forming the compiling party's hash function on the architecture specific program code, and (C) comparing the 
decrypted message digest and the test message digest of the architecture specific program. 
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